1. Field of the Invention
This invention relates generally to digital energy networks and more specifically to monitoring and controlling industrial energy equipment.
2. Description of the Background Art
For enterprises where power is critical, it is desirable to integrate power consumption and power generation devices into a digital energy network that enables centralized monitoring and management of the devices. For example, a hospital needs to monitor its power supply and energy consumption to ensure it has adequate power for all the equipment in the hospital. If there is a disruption in the main power supply, the hospital needs to switch to backup power sources, and it may need to quickly turn off certain non-essential equipment. Similarly, an industrial manufacturing facility may want to monitor its power supply and consumption to ensure it is using energy efficiently. It may switch between energy sources and turn on/off equipment in order to lower the cost of its energy expenses.
FIG. 1 illustrates an example of a typical digital energy network. A central server 110 (within an enterprise or in the cloud) monitors and controls an enterprise's industrial energy equipment, which includes power consumption and power generation devices 130a-130i. The central server obtains output data from and sends control data to the industrial energy equipment via programmable logic controllers (PLCs) 120a-120c. Specifically, the PLCs obtain raw output data from the equipment, normalize the data, and send it to the central server. Similarly, to control industrial energy equipment, the central server sends control data to the PLCs, which then write the data to specific memory registers in the equipment.
An enterprise/facility may have many different types of industrial energy devices. Generators, switchgears, automatic transfer switches, fuel systems, pumps, chillers, renewable energy sources, and building automation systems are just a few examples. There are usually multiple manufacturers and models for each type of device. Also, the age of the devices can vary greatly. The PLCs may be connected to recently built devices as well as machines that are twenty or thirty years old. Each PLC in a digital energy network may be connected to a different combination of devices.
There is no universal interface for reading and writing data from all these different types of industrial equipment devices. Instead, for each device, data must be read from and written to specific memory registers based on specifications obtained from the manufacturer of the device. Currently, an automation protocol, such as Modbus, is used for communications between the central server and the PLCs, as well as between the PLCs and the industrial energy devices. The PLCs are programmed on a “register-by-register” basis. Specifically, firmware loaded onto each PLC specifies the registers on the industrial energy devices at which output data is to be obtained and the registers on the PLC at which the data should be stored. The firmware may also instruct the PLC to perform a certain calculation (e.g., scale) on data in specified registers and the store the results in other specified registers. When the central server requests the data from the PLC, it references specific register addresses and a port on the PLC. Thus, the central server must know the register addresses at which desired data is stored on the PLC. To do this, an input/output (I/O) register map is created that maps registers on the industrial energy devices to registers on the PLC. The I/O map must specify specific input and output ports via which data can be retrieved. Each input and output on the PLC must be preconfigured and mapped to registers within the PLC.
Configuring the PLCs is tedious, expensive, and time consuming because the combination of devices to which a PLC is connected can vary greatly. There are two ways in which the PLCs are currently configured. One way is to load custom firmware on each PLC. To do this, an I/O register map must be created for the specific devices connected to that PLC. If the devices connected to the PLC change, the I/O register map and the firmware for the PLC must be changed as well.
Another way to configure the PLCs is load the same firmware on each PLC. Such firmware must anticipate all the likely combinations of devices that will be coupled to the various PLCs. To do this, registers, inputs, and outputs must be reserved on each PLC for each potential device that may be connected to the PLC. For example, if eight chillers may be connected to a PLC, then registers need to reserved on the PLC for eight chillers. If there are three different manufacturers of chillers, then registers need to be reserved for twenty-four chillers (eight from each manufacturer), as each manufacturer will require a different I/O register map. The firmware code set becomes enormous and essentially unmanageable once all the potential types of devices, manufacturers, and models are taken into account. In addition, there may not be enough registers on the PLCs to account for all the various combinations. Moreover, every time there is a change to the configuration file, all the PLCs must be updated.
In view of the above, it is clear that this is a great need for an easier and more efficient way to monitor and control energy devices.